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ABSTRACT 

A  clear  and  accurate  understanding  of  communication 
network  performance  is  essential,  especially  where  all  lay¬ 
ers  of  the  protocol  stack  -  from  physical  propagation  to 
application  transport  protocols  -  must  be  accounted  for. 
While  some  solutions  exist  for  RF  communications  over 
‘ open-terrain '  areas,  the  urban  environment  is  particu¬ 
larly  challenging.  To  meet  this  challenge,  a  server-based, 
real-time  solution  for  assessing  complex  communication 
and  network  effects  in  urban  environments  has  been  devel¬ 
oped.  By  combining  advanced  RF  ray-tracing  propagation 
modeling  and  a  full  network  simulator,  the  Scalable  Urban 
Network  Simulation  (SUNS)  software  is  able  to  provide 
accurate  communications  effects  services.  SUNS  supports 
tactical  modeling  and  simulation  by  predicting  electro¬ 
magnetic  signal  coverage  and  path  loss  through  applica¬ 
tion  of  a  full  3D  physical  knowledge  of  the  urban  environ¬ 
ment  and  terrain  features.  The  commercial  OPNET 
network  simulator  is  used  as  the  core  of  the  system,  with 
SUNS  operations  supported  through  a  custom  OPNET 
model  that  functions  as  a  modeling  and  simulation  server. 
The  server,  in  turn,  communicates  with  other  node  models 
within  the  OPNET  simulation.  In  the  approach,  urban 
propagation  data  are  pre-computed  using  high- 
performance  computing  (HPC)  resources  utilizing  ray 
traced  models  of  the  urban  scene. 

INTRODUCTION  AND  BACKGROUND 

Assessing  the  performance  of  wireless  communication 
networks,  including  impact  at  higher  tactical  levels  (e.g., 
military  /  force  level),  represents  an  ongoing  challenge  in 
communications  systems  modeling.  We  can  view  the 
communication  system  in  accordance  with  the  protocol 
layers  inherent  in  layered  protocol  design.  At  the  lower 
layers,  physical  effects  such  as  antenna  performance  and 
RF  propagation  are  of  paramount  importance  along  with 
media  access  control  (MAC).  Internet  protocol  (IP)  and 
routing  generally  form  the  next  layers,  while  transport  pro¬ 
tocols  such  as  UDP  and  TCP  occupy  the  next.  Above  these 
layers  reside  applications  which  can  operate  autonomously 
or  act  as  directed  by  users.  In  tactical  environments,  these 
applications  operate  as  driven  by  the  demands  of  users  or 
of  tactical  applications. 


We  can  see  that  the  multilayer  communications  stack 
forms  an  environment  wherein  each  Tayer’  not  only  util¬ 
izes  the  layers  above  and  below,  but  also  wherein  each 
layer  must  dynamically  react  to  those  around  it.  For  exam¬ 
ple,  if  a  communication  fails  at  the  transport  or  tactical 
operational  level,  it  might  be  retried;  packet  errors  or  drops 
may  cause  other  layers  such  as  routing  or  transport  to  react 
in  various  ways.  While  ‘cross-layer’  design  [1,2]  attempts 
to  optimize  performance  by  easing  the  strict  separation  of 
protocol  layers,  networked  communications,  and  its  simu¬ 
lation,  still  primarily  operate  as  a  discretely  layered  envi¬ 
ronment.  Unlike  prior  communication  effects  server  efforts 
[3-5],  the  SUNS  system  is  focused  on  the  urban  environ¬ 
ment.  This  provides  a  particularly  challenging  problem. 

A  comprehensive  approach  to  military  operational  assess¬ 
ments  therefore  requires  communications  modeling  that 
takes  on  a  holistic  approach  to  account  for  the  full  interac¬ 
tion  of  all  communications  layers  -  including  high  level 
tactical  layers  as  well.  However,  the  computational  as¬ 
pects  of  these  layers  are  much  different.  Antenna  modeling 
and  propagation  rely  on  lengthy  physical  domain  electro¬ 
magnetic  (EM)  calculations;  the  network  and  other  layers 
generally  make  use  of  discrete  event  simulation.  Yet  while 
both  the  network  and  upper  layers  make  use  of  discrete 
event  simulation,  they  are  each  large  independent  pro¬ 
grams.  In  our  case,  the  primary  client  that  operates  at  the 
upper  layer  is  the  OneSAF  system  [6].  This  mix  of  model¬ 
ing  environments  naturally  leads  to  use  of  a  client/server 
software  architecture  as  attempting  to  combine  these  tools 
into  a  single  executable  process  would  be  difficult  and  the 
result  unmanageable. 

ARCHITECTURE 

The  basic  architecture  of  the  SUNS  server  solution  is 
shown  in  Figure  1.  A  custom  model  is  built  into  the  net¬ 
work  simulator  to  provide  the  server  interface.  This  model¬ 
ing  component  communicates  with  each  node  within  the 
network  simulation  to  enable/disable,  relocate  and  initiate 
simulated  communications  as  directed  by  the  client.  As 
communications  occurs,  either  as  explicitly  requested  by 
the  client  or  as  the  result  of  routing  or  media  access  layer 
operations,  propagation  data  requests  take  place  to  deter¬ 
mine  point  to  point  losses.  These  loss  requests  are  handled 


1  of  6 


Report  Documentation  Page 

Form  Approved 

OMB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 

1.  REPORT  DATE 

01  OCT  2007 

2.  REPORT  TYPE 

N/A 

3.  DATES  COVERED 

4.  TITLE  AND  SUBTITLE 

Scalable  Urban  Network  Simulation  (SUNS) 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

OpCoast  Brick,  NJ 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS (ES) 

10.  SPONSOR/MONITOR’S  ACRONYM(S) 

11.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release,  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

The  original  document  contains  color  images. 

14.  ABSTRACT 

15.  SUBJECT  TERMS 

16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 
ABSTRACT 

uu 

18.  NUMBER 
OF  PAGES 

6 

19a.  NAME  OF 
RESPONSIBLE  PERSON 

a.  REPORT 

unclassified 

b.  ABSTRACT 

unclassified 

c.  THIS  PAGE 

unclassified 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


n 

OneSAF 

'1 

SUNS  Client 

SUNS 


Network  Sim  (OPNET) 


ri'SEI 


SUNS  Server  built  into  OPNET 


Wireless  models  use  RF  prop, 
computation  -  user  defined 
transceiver  pipeline  in  OPNET 


Urban  Propagation 


WkdaMk 

■  “■«—  I -A 

ter'—""" . *1 WJ 

5ar.«t>S*^ 


Pre-Goinputed 

Propagation 

DB 


DB  API 

hooked  into  OPNET  transceiver  pipeline 


Fig.  1 .  SUNS  Architecture. 


by  a  modification  of  the  simulator  code  that  enables  access 
to  a  database  containing  pre-computed  propagation  data 
for  the  urban  scene  under  study. 

The  details  of  the  OPNET  [7]  models  and  the  propagation 
database  and  its  computation  are  presented  in  later  sec¬ 
tions.  SUNS  and  the  clients  communicate  via  TCP  or 
UDP.  Client/server  message  formats  follow  that  as  speci¬ 
fied  in  the  Communications  Effects  Server  (CES)  [8],  with 
a  few  extensions.  The  messages  of  primary  importance 
allow:  creation  and  deletion  of  a  radio  node,  status  and 
location  updates  to  a  node,  communication  effects  requests 
and  responses. 

OPNET  MODELS 

The  primary  models  developed  for  SUNS  in  the  OPNET 
framework  include  the  SUNS  server,  which  only  exists  as 
an  interface  and  not  as  a  communication  node  within  the 
simulation  itself,  and  the  wireless  radio  node  models  that 
interact  with  the  server  and  the  general  simulation  frame¬ 
work.  Figure  2  shows  some  of  the  node  and  process  mod¬ 
els  used  in  SUNS.  Finite-state  based  process  models  form 
the  core  of  the  modeling  basis.  For  the  states  that  are 
shown  in  red,  the  simulation  stops  within  the  state  execut¬ 


ing  model  C++  code  before  the  stop  and  the  simulation 
continues  whenever  an  ‘interrupt’  is  received  wherein  ad¬ 
ditional  code  is  executed  within  the  state.  Code  is  executed 
within  states  shown  in  green  as  well,  but  the  simulation 
does  not  stop  within  the  state.  In  the  server  process,  only 
‘self-interrupts’  and  ‘remote-interrupts’  are  used  in  our 
modeling  approach  as  will  be  explained  later. 

The  server  process  is  composed  of  an  initialization  state, 
followed  by  an  idle  state.  In  the  initialization  state,  the 
server  initializes  an  external  socket  for  client  communica¬ 
tions  and  discovers  and  disables  all  mobile  nodes  within 
the  scenario.  The  server  then  sends  a  self  interrupt  which 
will  later  trigger  moving  to  the  idle  state.  Prior  to  reaching 
the  simulation  stop  point  in  the  idle  state,  a  check  is  made 
for  any  incoming  messages  from  SUNS  clients.  If  no  in¬ 
coming  messages  are  received,  a  self  interrupt  is  sent  after 
0.1  second.  This  will  cause  the  simulation  to  follow  the 
‘ALL  OTHER’  transition  back  to  the  idle  state  after  0.1 
second  which  then  rechecks  for  incoming  client  messages. 
In  this  way,  incoming  client  requests  are  checked  ten  times 
per  second  (the  simulation  runs  in  real  time  with  clients, 
not  at  maximum  simulation  speed).  The  server  also  checks 
for  previously  sent  messages  that  were  never  received  (ex- 
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Fig.  2. 

plained  later).  During  this  loop  period,  however,  a  remote- 
interrupt  might  be  received  which  can  only  indicate  that 
one  of  the  mobile  nodes  in  the  simulation  has  completed  a 
message  reception.  This  causes  a  transition  to  the  RECV 
state,  which  returns  a  communication-effects-response 
message  to  the  SUNS  client. 

Among  others,  messages  that  the  server  may  receive  from 
a  client  include  those  to  ‘create’  a  platform,  up¬ 
date/relocate  a  platform,  and  to  initiate  a  communication- 
effects-request  between  two  nodes.  Upon  receipt  of  a  cre¬ 
ate  platform  type  message,  the  SUNS  server  activates  a 
mobile  node  in  the  simulation  while  keeping  track  of  the 
mapping  between  the  client  and  the  simulator’s  internal 
nodal  identification.  During  the  message  processing,  nodes 
are  positioned  according  to  the  location  specified  by  the 
client  using  GCC  coordinates.  A  communication  effects 
request  message  from  a  client  will  cause  the  SUNS  server 
to  send  a  remote  interrupt  to  the  simulated  node  that  is  de¬ 
fined  as  the  sender  of  the  message. 

Figure  2  also  shows  the  disposition  of  the  mobile  nodes 
within  a  simple  scenario  and  expansions  of  their  internal 
processes.  The  mobile  node  model  is  an  extension  of  the 
OPNET  built-in  mobile  node  model  that  adds  the 
FMSinteractor  process  which,  in  turn,  interfaces  to  other 


OPNET  models. 

node  modules  at  the  UDP  or  TCP  level.  The 
FMS_interactor  process  is  shown  in  the  upper  left  hand 
corner  of  the  figure.  During  initialization,  the 
FMS  interactor  process  issues  ‘UDP  listen  to  port  5000’ 
(arbitrary  number)  commands  to  the  UDP  layer1  so  that 
the  model  will  send  incoming  packets  on  port  5000  up  to 
the  FMS  interactor  process  via  a  ‘stream  interrupt’.  Fol¬ 
lowing  initialization  in  the  init  state,  the  model  enters  an 
idle  state  which  just  awaits  simulation  interrupts.  If  a  re¬ 
mote  interrupt  is  received,  the  model  transitions  to  the 
FMS  send  state.  By  design,  the  only  remote  interrupt  that 
this  model  will  receive  is  from  the  SUNS  server  model  for 
initiation  of  a  communication  effects  request.  The  model 
uses  the  mapping  of  client  naming  for  the  receiver  to  de¬ 
termine  the  model  name  and  IP  number  for  the  receiver 
and  sends  a  simulated  UDP  message  of  the  size  requested 
by  the  client  to  the  model’s  UDP  layer. 

This  simulated  message  may  or  may  not  eventually  arrive 
at  the  receiver,  but  if  it  does  it  is  sent  to  the 
FMS  interactor  process  as  a  stream  interrupt.  The 
FMS  interactor  process,  upon  receipt  of  this  stream  inter¬ 
rupt,  transitions  to  its  UDPrecv  state,  which  then  sends  the 


1  Only  simulated  UDP  is  used  at  present.  TCP  operation,  which  requires 
additional  setup  and  teardown,  is  not  explained  here. 
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remote  interrupt  to  the  SUNS  server  for  processing  and 
eventual  return  of  a  successful  communications  effects 
response.  However,  what  if  the  message  transmission  be¬ 
tween  communications  nodes  fails?  In  the  idle  state  of  the 
SUNS  server,  a  check  is  made  for  previously  sent  mes¬ 
sages  that  never  where  received;  if  such  a  message  exists 
for  over  2  seconds  the  server  concludes  that  this  message 
will  never  arrive  and  returns  a  failed  communication  ef¬ 
fects  response  message  to  the  client.  Note  that  this  ‘time¬ 
out’  period  would  have  to  be  adjusted  upward  for  very 
long  messages.  Also  note  that  during  the  simulated  mes¬ 
sage  sending  that  all  routing  protocol  actions,  IP  level  op¬ 
erations  (such  as  packet  fragmentation),  and  media  access 
layer  actions  are  all  occurring  simultaneously.  All  RF 
propagation  loss  requests  from  OPNET  utilize  the  pre¬ 
computed  propagation  values  (described  next). 

URBAN  PROPAGATION  DATABASE 

The  primary  scenario  of  interest  includes  a  very  dense  ur¬ 
ban  area  approximately  6x3  km.  At  the  radio  communica¬ 
tion  frequency  of  interest,  ray-tracing  [9]  is  warranted  as 
the  proper  EM  approach.  Although  any  tool  can  be  used  to 
provide  data  for  the  propagation  database,  EMAG  Tech¬ 
nology’s  EMLounge  [10]  is  the  tool  applied  in  urban  ray 
tracing.  This  tool  provides  several  features  conducive  to 
achieving  necessary  results  such  as  the  separation  of  user 
interface  and  solver  and  the  solver’s  ability  to  use  high 
performance  parallel  computers.  To  help  understand  the 
data,  Figure  3  shows  a  graphical  result  of  a  propagation 
computation  (various  buildings  are  shown  blue  in  color).  A 
transmitter  is  located  near  the  center  of  this  small  scene 
and  propagation  losses  to  receivers  over  the  area  are 
shown. 


Fig.  3.  Ray  traced  Results 


As  propagation  computations  in  even  subsets  of  this  com¬ 
plex  environment  require  hours  of  compute  time,  propaga¬ 
tion  losses  must  be  pre-computed.  The  physical  complex¬ 
ity  of  the  area  does  not  permit  analysis  of  the  entire  scene. 


These  facts  give  rise  to  resolving  several  interrelated  issues 
which  will  now  be  described. 

The  most  straightforward  pre-computation  would  place 
potential  transmitter  (Tx)  and  receiver  (Rx)  sites  in  a 
closely  spaced  grid  over  the  entire  space  and  store  the  re¬ 
sults  in  a  database  for  later  access.  However,  the  scale  of 
the  scenario  does  not  allow  this  approach.  Our  solution  is 
to  use  potentially  overlapping,  variable-sized  ‘zones’ 
within  the  scenario.  The  data  for  each  zone  is  stored  in  a 
‘result  table’  while  a  single  ‘directory  table’  provides  or¬ 
ganization  of  multiple  result  tables.  The  results  tables 
would  provide  propagation  data,  as  computed  by  ray  trac¬ 
ing,  over  short  distances.  Longer  distance  data  relies  on 
propagation  loss  computations  through  simple  empirical 
models  [11-13].  Use  of  empirical  models  for  long  urban 
distances  is  due  to  limitations  in  being  able  to  analyze  the 
very  large  numbers  of  buildings  in  the  intervening  and  sur¬ 
rounding  area  Moreover,  as  the  zones  do  not  have  to  be 
regularly  spaced  nor  are  confined  to  a  grid  and  are  in  sepa¬ 
rate  tables,  updating  the  data  with  more  refined  results 
over  time  is  simpler.  For  example  as  computational  power 
and  memory  capacity  increases,  analysis  over  larger  zonal 
sizes  will  be  possible;  we  can  then  remove  the  smaller 
zone  tables  and  insert  zones  of  larger  size.  No  changes  in 
the  network  level  model  are  required  to  provide  this  en¬ 
hancement. 


Fig.  4.  Zone  Example 


Figure  4  illustrates  the  zone  concept.  The  set  of  larger  or¬ 
ange  points  that  span  the  overall  area  is  a  zone,  two  other 
zones  at  closer  spatial  resolution  are  also  shown.  In  this 
example,  the  directory  table  would  have  two  entries  refer¬ 
encing  two  result  tables  for  each  of  these  zones.  In  general, 
the  zone  is  a  set  of  Tx/Rx  locations  within  a  rectangular 
area  (its  actually  a  3D  box  since  elevation  is  also  in¬ 
cluded).  In  the  application  of  the  RF  analysis  tool,  the 
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Tx/Rx  sites  are  regularly  spaced,  but  there  is  no  such  re¬ 
quirement  in  the  database  design.  A  ‘level  of  accuracy’ 
(LOA)  is  also  associated  with  each  result  table,  and  in  this 
case  the  course  zone  would  have  a  lower  proclaimed  LOA. 

The  directory  table,  called  prop_directory  in  the  data¬ 
base,  has  the  following  fields  (ignoring  elevation  for  the 
moment): 

id  tool  version  model  loa  resolution 

freq  polarization  table_name 
latl  lat2  lonl  lon2 

which  provides  the  database  id  key,  the  tool  used  to  create 
the  data,  the  version  of  the  tool,  the  model  used  within  the 
tool,  the  LOA,  the  basic  spatial  resolution  of  the  data,  the 
frequency  in  MHz,  the  antenna  polarization,  the  name  of 
the  table  (this  is  the  ‘pointer’  to  the  result  table),  the  range 
of  the  zone  in  GCC  lat/long  units,  respectively.  Each  result 
table,  again  ignoring  elevation,  has  the  following  fields: 

id  rlat  rlon  tlat  tlon  loss 

which  gives  the  primary  id  key,  the  receiver  location 
(lat/long),  the  transmitter  location,  and  the  propagation 
loss  value,  respectively. 

During  simulation,  the  propagation  request  attempts  to 
retrieve  the  ‘closest’  match  from  the  database.  This  match, 
however,  is  a  function  of  the  following  parameters:  fre¬ 
quency,  Rx  and  Tx  location,  table  resolution,  and  the  level 
of  accuracy.  Our  current  search  approach  is  to  locate  the 
propagation  data  table  that:  (i)  includes  the  Rx  and  Tx  lo¬ 
cation  in  the  zone  (this  is  basically  not  negotiable),  (ii)  that 
has  a  frequency  match  within  1  KHz,  and  (iii)  among  the 
possible  tables,  use  level  of  accuracy  as  a  primary  sorting 
value  and  resolution  as  a  second.  The  steps  needed  to  ex¬ 
tract  the  best  propagation  loss  value  now  follow. 

The  first  step  is  to  consult  the  directory  table 
(prop_di rectory)  to  find  which  tables  include  the  zone 
of  interest  covering  the  Rx/Tx  points.  Both  of  these  must 
be  within  the  bounds  indicated.  This  step  may  return  more 
than  one  table  as  zones  can  overlap  or  be  subsets  of  each 
other.  Furthermore,  each  potential  table  cold  reflect  dif¬ 
ferent  levels  of  accuracy  and  resolutions.  For  Rx  and  Tx 
points  of  22.1/33.2  and  22.0/33.1  (lat/long)  at  a  frequency 
of  2.4  GHz,  the  following  SQL  statement  works  to  select 
the  result  table  with  the  best  LOA  and  secondarily  resolu¬ 
tion  for  a  zone  within  a  frequency  match  of  1  KHz  (0.001 
MHz): 

SELECT  id, table_name  FROM  prop_directory 

WHERE  (22.1  BETWEEN  latl  AND  lat2) 

AND  (33.2  BETWEEN  lonl  AND  lon2) 

AND  (22.0  BETWEEN  latl  AND  lat2) 


AND  (33.1  BETWEEN  lonl  AND  lon2) 

AND  (ABS (2400-freq)  <  0.001) 

ORDER  BY  loa  DESC,  resolution  LIMIT  1 

This  will  choose  the  table  that  covers  the  Rx/Tx  points 
with  the  highest  LOA  (from  the  ORDER  BY  loa 
DESC,  resolution  LIMIT  1  phrase)  with  a  secon¬ 
dary  search  criteria  of  lowest  resolution;  note  reversing 
these  clauses  would  result  in  finding  the  table  with  the 
highest  resolution  first  and  then  secondarily  using  LOA.  If 
there  are  applicable  tables  with  equal  LOA  and  resolution 
then  an  arbitrary  one  is  chosen  by  this  statement. 

After  this  statement  is  used  to  select  a  propagation  data 
table,  say  called  prop_v_900_2,  it  is  then  queried  to  get 
the  loss  for  the  closest  match  to  the  Rx/Tx  points  as  the 
sum  of  the  squares  of  differences  (metricvalue  in  the 
SQL  statement): 

SELECT  id, loss, 

(ABS ( (rlon- 33 . 2) * (rlon- 33 .2)  + 

(rlat-22 . 1) * (rlat-22 . 1) )  + 

ABS ( (tlon-33 . 1 ) * (tlon-33 . 1 )  + 

(tlat-22 . 0 ) *  (tlat-22 . 0 )  )  )  AS  metricvalue 
FROM  prop_v_900_2  ORDER  BY  metricvalue  LIMIT  1 

Note  that  this  approach  doesn’t  allow  for  finding  an  alter¬ 
nate  table  which  might  have  better  point  matches  (resolu¬ 
tion)  but  not  as  good  LOA.  Other  search  tradeoffs  such  as 
softening  the  frequency  match  to  find  better  resolution  or 
LOA  matches  can  be  performed  with  alternate  queries 
One  way  to  try  these  tradeoffs  is  to  eliminate  the  ‘LIMIT 
1  ’  phrase  in  the  initial  search,  or  change  the  1  to  a  higher 
value,  and  then  search  each  of  the  propagation  data  tables 
returned.  Also,  right  now  we  are  only  putting  data  with 
vertical  polarization  into  the  database,  so  this  is  not  a 
search  criteria;  but  of  course  the  database  design  properly 
supports  polarization  parameters. 

CONCLUDING  REMARKS 

The  primary  models  developed  for  SUNS  in  the  OPNET 
framework  include  the  SUNS  server  and  the  wireless  radio 
node  models  that  interact  with  the  server  and  the  general 
simulation  framework.  These  models,  combined  with  our 
urban  propagation  database  and  propagation  lookup  ap¬ 
proach,  create  a  server-based  resource  for  accurate  com¬ 
munication  effects  in  complex  urban  environments.  A  par¬ 
ticular  client  for  the  SUNS  system  is  the  One  Semi- 
Automated  Forces  (OneSAF)  system.  The  interaction  of 
OneSAF  and  the  SUNS  Server  account  for  real-time  com¬ 
munication  effects  that  include  all  protocol,  routing,  IP, 
MAC  and  propagation  effects.  This  enhanced  functionality 
will  provide  for  more  advanced  network  centric  training, 
analysis  and  experimentation  for  urban  environments  as 
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well  as  provide  pertinent  feedback  to  communication  net¬ 
work  developers. 

The  work  is  sponsored  by  the  DoD  High  Performance 
Computing  Modernization  Office  (HPCMO)  under  the 
Office  of  the  Secretary  of  Defense. 
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